CROSS-REFERENCES
Related Applications: This application is one of four U.S. patent applications being filed simultaneously, all of which are commonly assigned, namely:
Ser. No. 07/970,335, METHOD OF DYNAMICALLY CANCELING A DB2 THREAD, by David L. Janicek; PA1 Ser. No. 07/970,334, METHOD OF DYNAMICALLY EXPANDING OR CONTRACTING A DB2 BUFFER POOL, by David L. Janicek; PA1 Ser. No. 07/970,337, METHOD OF DYNAMICALLY EXPANDING A DB2 EDM POOL, by David L. Janicek; PA1 Ser. No. 07/970,336, METHOD OF DYNAMICALLY ADDING OR REMOVING DB2 LOGS, by Anouar Jamoussi and David L. Janicek.
Microfiche Appendix: The microfiche appendix to this specification contains source code listings of a series of copyrighted computer program routines that are the property of the assignee of this application. Permission is granted to make copies of the appendix and its contents solely in the course of creating facsimile copies of a patent issuing on this application and for no other purpose. All other rights under copy-right or similar law are reserved.
Glossary and Bibliography: A general-purpose glossary of certain terms of art and a list of potentially helpful references for further reading are set out as an appendix to the printed specification of this application. References are indicated in the text of the specification in conventional fashion, e.g., "[Smith]" might indicate an article by Smith. Both the glossary and the list of references are intended solely as an aid to understanding the invention and not as limiting the scope of the inventive subject matter defined in the claims.
The DB2 Database System
This invention relates to the use of database software such as the well-known DATABASE 2 database software distributed by IBM Corporation, commonly referred to colloquially in the art as "DB2." As is well known to those of ordinary skill, generally speaking DB2 operates as a subsystem in a computer system that itself is operating under the IBM MVS operating system software. More specifically, the invention relates to a method by which a user of a DB2 application can dynamically add and remove DB2 active logs without affecting the availability of the database system or of DB2 applications.
Generally speaking DB2 operates as a subsystem in a computer system that itself is operating under the IBM MVS operating system software. A given MVS system may have more than one DB2 subsystem operational at any particular time. In this specification the term "DB2" is used to refer to an arbitrary single DB2subsystem.
FIG. 1 illustrates, in greatly simplified form, one typical type of configuration in which DB2 is used. In such a configuration, DB2 interacts with the well-known IBM Time Sharing Option (TSO) software. An application program labeled "DB2 APPLICATION" indirectly makes use of DB2-provided services, via calls to TSO, to read from and write to data storage labeled DASD. Such an application program is commonly referred to generically in this context as a "DB2 application." The DB2 application typically communicates indirectly with a user via calls to communications management software such as, e.g., the well-known IBM Virtual Terminal Access Method (VTAM) software.
DB2 Logs
As is well-known to those of ordinary skill, DB2 maintains a number of "logs." A log is a linear data set (LDS) structured to conform to IBM's Virtual Storage Access Method (VSAM). In essence, a log serves as something like a logbook or chronological journal of DB2's activity. Generally speaking, when DB2 updates data in a DB2 object, the type of update event or transaction is recorded in a log along with both the old and new data. As a result, in certain circumstances involving corruption of dam, e.g., abnormal termination of a DB2 application, DB2 can attempt to use the logged information to recover as much of the corrupted data as possible. Such transactions are recorded initially in an "active log" in memory for quick access. The DB2 active log is the prime source of recovered data that has not been archived.
DB2 utilizes a fixed number of active logs, with the number and size of the logs being set at DB2 initialization time. DB2 may be configured by the database administrator (DBA) to maintain two or more active logs in memory, of which one is always the "current active log."
As illustrated in simplified form in FIG. 3, DB2 maintains the active logs as, in effect, a single logically infinite log by performing a round-robin type of operation, switching from a full active log (e.g., ACT3 if FIG. 3) to the least recently used active log data set (e.g., ACT1) and overwriting it. This normally does not cause a problem because the active-log information in the least recently used active log data set is ordinarily copied off to an archive log prior to being selected for overwriting. At the database administrator's option, the DB2 subsystem can be operated in "dual active log chain" mode. In that mode, for redundancy purposes the active log chain is kept in duplicate copies, referred to as copy 1 and copy 2.
During operation DB2 refers to a bootstrap data set (BSDS), illustrated in simplified form in FIG. 4, to determine what active logs are available. The bootstrap data set is a VSAM key sequence data set that in many respects functions as a restart data set; that is, the BSDS provides a storage area in which DB2 keeps track of its own current status in case it must be restarted (e.g., after a system failure).
The BSDS includes an active log copy 1 record; if the DB2 subsystem was started in dual active log mode the BSDS also includes an active log copy 2 record. Each of the active log copy 1 and 2 records comprise a 4K page of storage, which effectively limits the size of the active log chain because when the available space in the BSDS record is exhausted, no more active logs can be added. The BSDS also includes records in which DB2 keeps track of its archive data sets. Whenever DB2adds, or archives, an active log, it updates the active log record (including the active log's relative byte address or RBA, assigned by DB2) in the BSDS.
In FIG. 4, a BSDS key record includes an identifying code shown in the Figure as 04000001, followed by (i) the respective record keys of the active log copy 1 and copy 2 records, and (ii) the respective record keys of the archive log copy 1 and copy 2 records. Each of the active log copy 1 and copy 2 records includes the record's key followed by header information labeled HDR and by a series of fields labeled LOGe1, LOGe2, etc., each representing an active log and its status information such as its data set name, status flags (described in more detail below), RBA ranges, timestamps, etc.
As illustrated in simplified form in FIG. 5, DB2 also utilizes a log management control block (LMB) in managing its active logs. The LMB has "chained" to it (i.e., the LMB includes pointers to the head of a chain of) two or more control blocks LDSD in a circular chain, with each LDSD representing an active log data set labeled LOG. The LMB also includes a pointer to the current active log. In addition (but not shown in FIG. 5), the LMB includes a pointer ALW1, pointing to an in-memory (cached) copy of the COPY 1 BSDS record, and if in dual active log mode, a pointer ALW2 pointing to a similar cached copy of the COPY 2 BSDS record.
Each LDSD control block includes a status code for the associated log. The status codes include STOPPED (indicating that the log may not be used for some reason), NEW (indicating that the log may be used to write transaction records but that no such writing has yet occurred), TRUNCATED (used to indicate that only part of the log includes transaction data, e.g., because the log's duplicate or counterpart in a dual active log chain has a smaller storage capacity than the log), and REUSABLE (indicating that the contents of the log have been copied to permanent or archived storage and thus that the memory used for the log can be overwritten if necessary).
Active logs are always open and available to DB2 while DB2 is active. DB2writes transaction records to and reads transaction records from these logs on-line. Each active log is shared by all DB2 threads executing under that DB2 subsystem; more precisely, DB2 writes information for all associated DB2 threads to the current active log.
When no more storage is available in the current active log (e.g., because all storage in the current active log has been used up in writing transaction records), DB2switches to use the next active log in the chain. DB2 updates accordingly the LMB pointer to indicate that the next active log is now the current active log. DB2 also copies the contents of the former current active log to archival storage and sets the REUSABLE status code in the LDSD for that log. Log switching is also recorded by DB2 in the BSDS.
The Problem of Fixed DB2 Active Log Capacity
In environments where computer-system and application-program availability is a prime concern, it is normally desirable to have enough active log space to perform timely recovery. When a new DB2 application is brought up, for example, it can sometimes be difficult to predict how many insertions, deletions, and updates may occur in the data associated with that application. That in turn makes it difficult to predict the net additional active log requirements. If data compression is used in a DB2 application, it can be even harder to predict active log requirements. Data compression causes each row (record) to be treated as a variable-length row; that means that any change taking place in a column (field) will be logged as well as all dam to the end of the row in question. Moreover, although the current generation of DASD devices is generally regarded as quite reliable, and although DB2 has the ability to use dual active logs for redundancy, I/O errors can still pose problems of downtime or concern about the availability of DB2.
One long-recognized problem with DB2 is that neither the number nor size of the active DB2 logs can be increased or decreased dynamically. Thus, tuning of the active logs is not feasible without bringing down DB2 (i.e., terminating the execution of DB2), changing the parameters defining the active log number and size, and bringing DB2 back up. The process of bringing DB2 down for the purpose of making parameter changes, then bringing it back up again, is sometimes referred to as "cycling" DB2. Cycling of DB2 frequently results in serious inconvenience to users of DB2 because bringing down DB2 necessarily causes an outage (i.e., unavailability) of all application programs that use DB2. Thus, data bases supported by those application programs become unavailable to users for the duration of the outage.
A related problem is associated with correcting I/O errors on-line. DB2 marks any bad active log associated with such an error as STOPped; correcting the error may require cycling DB2, especially if the STOPped log is the only active log remaining.
Furthermore, if DB2 must recover corrupted data (e.g., if a table space becomes corrupted), the recovery process generally proceeds much faster if it utilizes an active log as opposed to an archive log. If a database administrator installs ("brings up") a new DB2 application, a situation may occur in which the amount of active log space is suboptimal, possibly resulting in degraded performance and recoverability.
A long-felt need has thus existed among database administrators for the capability of dynamically adjusting the active log parameters of DB2 without cycling DB2.